The present invention relates generally to the field of communications networks. More particularly, the present invention relates, in one aspect, to controlling the operation of such networks pursuant to one or more network operational policies. Still more particularly, aspects of the present invention relate to networks including policy-enabled devices, such as routers, switches and the like, that are responsive to distributed policy messages for device configuration and operation.
Modern communications networks, including private and public data networks (such as Wide Area Networks, and the Internet) comprise a (usually large) number of interconnected network nodes. These nodes each contain one or more of a variety of network devicesxe2x80x94such as repeaters, concentrators, routers, bridges, switches and hubsxe2x80x94for relaying, combining, directing and otherwise handling information in its transit across the network. Each device has traditionally been configured and controlled for its intended function under the control of a human network administrator using table-driven configuration and control information. The device settings for a particular mode of operation generally depend on the type of device, and usually vary for devices of the same type when supplied by different manufacturers.
While some network nodes, and devices at such nodes, remain in one configuration and operational state for some time, others require reconfiguration frequently to reflect changing network conditions and operational preferences. Thus, for example, if traffic arriving at a particular node increases, or priorities for particular data streams through a node change, it may be necessary to adjust (configuration, filter or other) table settings at one or more network nodes. Frequently, configuration and other settings are dictated, in part, by Quality of Service (QoS) commitments made to particular users or classes of users. Other configuration changes are required to reflect network service changes, as when new or modified network applications are introduced.
To avoid the tedious and error-prone manual adjustment of configuration settings at network nodes, a number of network management tools have been developed. These tools have generally allowed centralized administration of a plurality of nodes through the sending of messages to replace or update routing and other tables at affected nodes.
More recently, a directory-based approach has been used to effect changes at nodes in some networks. In accordance with one implementation of directory-based controls, a directory server transmits information in a directory to a network node to be updated, often using the well-known Lightweight Directory Access Protocol (LDAP) adopted as a standard by the Internet Engineering Task Force (IETF). Directory contents received at the node are used to wholly or partially replace or update configuration and related operational information previously stored at the node. The same directory information may be used for updating more than one node (or all nodes) in a network. Directory information used for such updating has traditionally been supplied by a network administrator, as have the directories applicable to particular nodes and particular circumstances (such as changes of QoS or user priorities).
With the increasing diversity of network users, applications and available services, networks of even modest complexity have given rise to the need for unified policy-based control and configuration. Attempts have been made to introduce policy servers suitable for formulating directory information appropriate for delivery to network devices for effecting the policies reflected in the directory contents. In accordance with a current xe2x80x9cpullxe2x80x9d model, directory information is sought to be provided in response to a request by a network device upon device boot-up, or upon some change in operation of a device or network application. Such proposed pull methodology is to be contrasted with prior xe2x80x9cpushxe2x80x9d approaches in which a central repository delivered (pushed) policy-based data to network devices.
FIG. 1 shows a simple prior art arrangement for delivery of a desired network policy to a network device using policy-based administration. There, a network manager establishes a policy for all or parts of a network using policy development tools, typically including a high level language and network and device definitions. The policy definition, including such QoS, authentication, encryption or other policy factors deemed important, is conveniently stored at a directory server, shown as 120 in FIG. 1, where it becomes accessible using LDAP. When a network device, such as 130 in FIG. 1, is booted up or receives a request by a user for some new or different service, device 130 issues a request for directions to a policy server, shown as 110 in FIG. 1. The policy server in turn issues a request of the directory server 120 for the information in the appropriate directory. Policy server 110 in typical fashion then forwards a copy of the requested directory information to the network device 130, often using simpler protocolsxe2x80x94such as the Common Open Policy Service (COPS) protocol. Other well-known protocols commonly used for dealing with information transfers between network devices and a policy server include the Remote Authentication Dial-In User Service (RADIUS), and its extension, DIAMETER.
While the policy server 120 in FIG. 1 is used to control policy behavior (relating, e.g., to security or QoS) of a network device such as 130 in FIG. 1, the policy server is not generally responsible for providing configuration information for individual network devices. Rather, such device configuration information is typically requested directly from the directory server ( 120 in FIG. 1) by each particular device. Again, access to directory information is facilitated using protocols such as the LDAP protocol.
FIG. 2 shows another representation of a prior art policy-based network control arrangement with two network devices 130-1 and 130-2 connected directly to directory server 120 over LDAP links 240 and 260 for the transfer of device configuration information. These network devices are also shown connected through policy server 110 to directory server 120. Illustratively, the connection 250 between policy server 110 and directory server 120 is also a LDAP link, while the policy-based information is transferred to representative network devices 130-1 and 130-2 over respective links 270-1 and 270-2xe2x80x94illustratively using the above-mentioned COPS protocol (for device 130-1) and the well-known DIAMETER protocol (for device 130-2). The data store 125 providing the directory storage facilities is also shown explicitly in the FIG. 2 network representation.
One policy-based approach to network administration, known as Directory Enabled Networks (DEN), has sought to define and relate problem domains, usage profiles, an information model and so-called xe2x80x9cschemasxe2x80x9d for integrating networks with directory services. Schemas are often defined in terms of classes of objects, each subject to inheritance, naming and other constraints, and each having identifiable attributes. For an example of a policy schema and illustrative class structures, see xe2x80x9cPolicy Framework Core Information Model,xe2x80x9d by the Internet Engineering Task Force, Nov. 17, 1998, available at search.ietf.org/internet-drafts/draft-ietf-policy-core-schema-00.txt.
An important factor in the use of a DEN or other prior policy-based network control is the adherence to the strict definitions, directory organization and language by the diverse vendors of network devices. Such vendors have traditionally sought to differentiate their product and service offerings from those of competitors by including proprietary features and extensions to industry standards. Thus, particular expressions of policy can be interpreted differently by network devices incorporating such proprietary extensions and features, thereby making uniform policy enforcement difficult or impossible.
Though arrangements like those shown in FIGS. 1 and 2 prove useful for many applications, they rely, ultimately, on tabular (or similarly structured) data stored in network devices for ready access upon arrival of data packets, cells or other input flows bearing associated characterizing (e.g., header) information. Thus, for example, a pattern match between particular packets, or classes of packets, causes prescribed actions (e.g., drop, delay, or an application of relative priority) by the network device. Such simple policies as allocating a prescribed bandwidth to packets of a particular class lend themselves to such table-driven policy prescription. Conditions based on awareness of local time can likewise be fairly simply accommodated. With more complex policies, however, and with a wide diversity of network devices (or even software releases for the same device), policy implementation becomes quite unwieldy or impossible using such static, table-driven techniques.
In another aspect, existing and proposed network policy paradigms place the policy decision point for implementing policy in a single, usually fixed, location. In particular, traditional SNMP models and the emerging LDAP model affix the decision point within network devices. For example, a network management application illustratively pushes a filter table into a network device (SNMP), or a network device pulls a filter table from a directory server (LDAP) as shown in FIGS. 1 and 2. In either case, the network device then consults the received filter table as it examines each packet that it handles. Using a policy server model employing RADIUS, DIAMETER, or COPS, moves the decision point out of the network device, but still provides for little flexibility. Optimizing policy implementation by selectively positioning the decision point is restricted by all of the current architectural models. As will be apparent to those skilled in the art, such optimization can be especially critical in implementing complex policies.
Complex policies generally reflect higher-level business goals. For example, to maximize the use of network resources, an enterprise may choose to disable local video traffic when local voice traffic requires more network resources. To implement such a policy, a network device must evaluate information not found in tables received using any protocol. The condition implies real-time analysis of bandwidth utilization and distribution.
It is often desirable to deploy complex policies in a variety of networks, including Wide Area Networks (WANs) interconnecting distributed locations of a corporation or other organization. Thus, for example, to ensure that mission-critical processes are not delayed in times of heavy traffic, an organization with offices in multiple cities may enable alternate routes, e.g., between its Chicago and St. Louis offices, when utilization of its primary link exceeds a threshold, such as 80%. In other cases, an organization seeking to balance Internet access may design a policy to limit a particular department""s outbound web traffic to 20% of the total bandwidth available. Similarly, to limit the interruption of voice services, network administrators may want devices to rebalance traffic isolation parameters when the voice traffic class exceeds 95% of allocated capacity. Each of these policies requires analysis of variables external to the packets affected by the policy. A simple table specifying a simple true/false expression and an action command cannot accommodate the expression of complex policies that dictate a procedural decision process.
Network devices capable of implementing complex policies desirably base decisions on a variety of external data sources. Such data sources for complex policies may include, but are not limited to, sources such as accounting and billing servers, name servers, external directory servers, centralized policy servers, and peer devices executing coordinated policy applications. A typical example of such a network device implementing a complex policy is a wide-area network (WAN) access switch communicating with a billing server before making a policy decision. Such policy implementation is not available using present directory-based policy implementation techniques. Further, table-based policy implementation at a particular node does not permit such real time observations as use of bandwidth consumption or congestion delay (among many others) to effectively adapt operation at the particular network node or other network nodes with which it is interacting. Delays inherent in deriving and propagating table-based policies simply do not permit the application of optimum network operation policies.
Limitations of the prior art are overcome and a technical advance is made in accordance with the present invention described in illustrative embodiments herein.
In one illustrative embodiment of the present invention, both simple and complex policy mechanisms are included in a new architecture for policy-enabled devices. Such policy-enabled devices advantageously contain a Data Access Client Module (DACM) and Policy Interpreter and Processor (PIP). The DACM illustratively establishes a data path between a network device and data stores containing device configuration information, and simple policy definitions, e.g., filter tables, and the like. A policy server comprising a DACM advantageously establishes a data path to a data store, as do DACMs at individual network devices. This policy server employs the data store for storing policy server configuration information, as well as more complex policy expressions, illustratively in a directory structure.
In accordance with other illustrative embodiments of the present invention, a distributed data model is presented which allows policy information to be efficiently retrieved not only from a centralized (usually replicated) directory server, but also from virtually all network devices. Using a data element registration system, data elements (including, in appropriate cases, directory-structured and other data, and executable modules) are associated with a particular owner network device and other network devices or applications requiring access to data elements to derive policy information and execute policy applications. Access is advantageously granted (e.g. a data element is delivered) by messages sent to the target associated network device, after the occurrence of some event (such as exceeding a prescribed bandwidth allocation or congestion level).
In an illustrative distributed-policy-enabled network of devices (e.g., data servers, routers, switches and the like) in accordance with an embodiment of the present invention, policy is imposed and modified by one or more policy applications executing in one or more network devices. Each of these network devices receives and sends data elements while presenting a standard, device-independent data structure to target external devices. Each network device accommodates the particulars of its internal infrastructure using a well-known schema, such as the core schema published by the DMTF and IETF standards organizations.